A Metamodel for Object-Oriented Statecharts

syntax static semantics dynamic semantics UML approach class diagrams OCL natural language Object-Z approach Object-Z class specs Object-Z predicates Object-Z operation & class diagrams in class specs specs Figure 4: Comparison of UML and Object-Z approach entities. We use Object-Z as a single formalism for the abstract syntax, the static semantics and the dynamic semantics. 1.5 Comparison to the UML Approach In the metamodel of UML 1.1 the object constraint language (OCL) [20] is used to express constraints between the entities of the metamodel. This is a major progress to compared version 1.0 [19]. In [22], the authors distinguish between abstract syntax, static semantics and dynamic semantics. We agree very much with this conceptual distinction. In the UML approach a di erent syntax is used for each of these aspects, see gure 4. Consequently, the relation between the three di erent aspects can only be expressed loosely, on an informal level. The approach proposed in this paper (abbreviated Object-Z approach) is to describe all aspects within one formalism, leading to a common vocabulary. Being thus closely related, the distinction between the aspects is still clear ( gure 4): classes, attributes and associations describe the abstract syntax, there is a natural mapping from class diagrams into an Object-Z specication. As in the UML approach, constraints on the attributes and associations are described by predicates. Dynamic semantics is de ned by the operations of the Object-Z classes. An advantage of our approach is that we do not have self-referencing problems, since Object-Z, as the logical basis for our foundation, is completely independent of the UML. For example consider the Generalization relationship, which is also used in the metamodel. We also re ect the Generalization relationship in our metamodel, but we use the inheritance mechanism of ObjectZ, which is explained syntactically as enrichment of a class. In this way, we are able to use the structure of the metamodel but we avoid any self-referencing problems. Up to now, the relationship between the class diagrams and the OCL is quite unclear. For example consider a constraint de ned in the superclass: Must the inheriting class ful ll this constraint? Is it possible to rede ne the operations of the OCL? These are important questions in order to understand the metamodel. Further, the general concept of the OCL semantics is not described in [20], e.g.: Does the OCL support value semantics (like Z) or reference semantics (like Object-Z)? Overall, the type system of the OCL is not clear. We use the UML metamodel [22] as a basis for further investigations, since the UML is a quasi-standard for object-oriented modeling. We are convinced that most CASE tools will support the UML standard and that the UML has an important impact on software engineering. But also from a purely scienti c point of view, we have chosen the UML since it provides the most elaborated metamodel. 1.6 Structure of the Paper In the following sections, we describe the metamodel for object-oriented statecharts using class diagrams and Object-Z. Section 2 gives a short overview of concepts in object-oriented statecharts. Abstract syntax and static semantics is introduced in section 3, dynamic semantics in section 4. The conclusion is given in section 5. The basic concepts of the formal object-oriented speci cation language Object-Z are sketched in the appendix. 2 OBJECT-ORIENTED STATECHARTS Statecharts are used for behavioral description of classes (specifying the intra-object dynamics) in several objectoriented methods, like [23, 4]. But in di erent methods di erent dialects of statecharts are used. These dialects di er in syntax and in semantics both, and the semantics has not yet been precisely de ned in any method. In [12] fundamental work has been done on more precise description of statecharts for object-oriented modeling, especially for executable modeling. Based on this conceptual work, the Rhapsody tool [14, 15] has been developed. It allows the speci cation, simulation and code generation for object-oriented statecharts. The UML metamodel for statecharts [22, p. 97{119] is based on the object-oriented version [12]. Although the notation of object-oriented statecharts is essentially the same as standard statecharts [11, 13] the semantics di ers considerably. Our metamodel for object-oriented statecharts formalizes statecharts as described in [22, 12, 14] specifying abstract syntax, static semantics, and dynamic semantics. According to Rhapsody [14] we call classes with an assigned statechart reactive. The behavior of instances of reactive classes depends on their internal control state. The states of a statechart represent abstract situations in the life-cycle of objects and de ne temporary invariants. In [12] two communication mechanisms are provided. Reactive objects are able to communicate 4 asynchronously and synchronously. Asynchronous communication is established by sending of events, while synchronous communication is established by operation calls. The statechart de nes both the reaction to a received event (asynchronous communication) and the reaction to ful ll an operation request. Both kinds of reactions are expressed by ring transitions which are triggered by the event or operation request. The type of events for asynchronous communication are called signals, the events themselves signal-events. The signals that a class can receive (or send) belong to the interface of the class. Operations whose e ects are speci ed by transitions are called triggered operations. A callevent is a received request for a triggered operation. In gure 5 the additional features of a reactive class are shown in a class diagram. PrimitiveClass operations 0..* Operation owner 1 Class /opns 0..* 0..* 0..* Signal 0..* triggered 0..* TriggeredOperation owner 1 primitives 0..* PrimitiveOperation owner 1 owner 1 ReactiveClass receive send /tr_opns /pr_opns stateMachine 1 StateMachine Figure 5: Reactive Class The di erence between requesting an operation of an object or sending a signal-event to this object e ects the statechart of the client object2. In case of requesting another object's operation, which is done while ring a transition, the execution of the client object's statechart is frozen in mid transition, because the thread of control is immediately passed to the server object. If the operation request was satis ed, i.e. the requested operation was performed by the server object, the thread of control is passed back to the client object, which proceeds with the ring of the rest of the suspended transition. In case of sending a signal-event, the client object retains its thread of control in order to complete its transition execution. 3 ABSTRACT SYNTAX AND STATIC SEMANTICS FOR OO-STATECHARTS In our approach, abstract syntax and static semantics is given by Object-Z classes and their state schemas where attributes and class invariants are de ned. For a better understanding and overview, class diagrams are given. 2We call an object which is requesting an operation from another object the client object. Analogously, the object that provides the requested operation is called the server object. In the following, a part of the metamodel for the abstract syntax and static semantics of object-oriented statecharts is presented which illustrates our approach to metamodeling and integration of di erent models. The complete metamodel is given in [18]. A statechart syntactically consists of a hierarchy of vertices and a set of transitions. Transitions are directed edges between some vertices. In statecharts several kinds of vertices are distinguished: states, pseudo-states and connectors.3 Common to all kinds of vertices is that they can be source and target of transitions in general. States can be decomposed in di erent ways. As in Statemate-statecharts [13] there are xor-states, andstates and basic states. If an xor-state is active, then exactly one of its substates is active, too. If an andstate is active, then all of its substates are also active. Basic states are atomic, i.e. they are not further re ned. Pseudo-states (i.e. default and history symbols) can be subnodes of an xor-state. They are used for the speci cation of several entering modes into this xor-state. Connectors are used for transition structuring. Basic elements for structuring a transition are transition segments. A sequence of some transition segments connected by connectors constitutes a compound transition. The source and target of compound transitions consist only of state-vertices. In our metamodel \state-vertice" is an abstraction for states and pseudo-states. In gure 6 an example statechart for a reactive class is shown. Various states are drawn there, e.g. basic1, xor2 and and1. The names of these states identify the type of the states they belong to. The hierarchy of states is shown by the encapsulation of states. Thus, the (direct) substates of and1 are xor1 and xor2. These two states are also called the components of the and-state and1. The state xor1 is further decomposed in the states basic3 and xor3, and so on. The edges named as t1, t2 etc. are transition segments. The sequence of t21 and t23 constitutes a compound transition. These two transition segments are connected by a junction connector (drawn as a black lled circle). Transition segment t10 starts at a default symbol (drawn as a black lled circle which has no incoming edges) and constitutes the default transition of the xor-state xor3. Transition segment t5 goes to a history symbol (a circled \H"). The circled \C" in the statechart is a condition connector. The transition segment t15 is an example for a transition with more than one source vertex. Transitions have a label consisting of a trigger, guard and action, which are optional. The guard is written inside the brackets \[" and \]" of the transition's label, see example statechart in gure 6. The action is written after the slash \/". The trigger of a transition is spec3The terminology for statecharts vertices di ers from the notions of the UML. 5